NIST SP 800-90A

決定論的乱数ビット生成器を用いた乱数生成に関する推奨事項

Recommendation for Random

Number Generation Using

Deterministic Random Bit Generators

権限

本出版物は、2014年連邦情報セキュリティ近代化法（FISMA）（44 U.S.C. § 3541 et seq.、公法（P.L.）113-283）に基づくNISTの法定責任を促進するために作成されました。NISTは、連邦情報システムの最低要件を含む情報セキュリティ標準およびガイドラインの策定に責任を負っていますが、これらの標準およびガイドラインは、当該システムに対する政策権限を行使する適切な連邦職員の明示的な承認がない限り、国家安全保障システムには適用されません。本ガイドラインは、行政管理予算局（OMB）通達A-130、第8b条(3)項「政府機関情報システムのセキュリティ確保」の要件に準拠しており、通達A-130の付録IV「主要セクションの分析」で分析されています。補足情報は、通達A-130の付録III「連邦自動化情報リソースのセキュリティ」に記載されています。

本出版物の内容は、商務長官が法定権限に基づき連邦政府機関に義務付け、拘束力のある基準およびガイドラインと矛盾するものではありません。また、これらのガイドラインは、商務長官、行政管理予算局長、またはその他の連邦政府職員の既存の権限を変更または置き換えるものと解釈されるべきではありません。本出版物は、非政府組織による自主的な利用が可能であり、米国における著作権の対象ではありません。ただし、出典を明記していただければ幸いです。

コンピュータシステム技術に関する報告書

米国国立標準技術研究所（NIST）の情報技術研究所（ITL）は、国の計測・標準化基盤における技術的リーダーシップを提供することで、米国経済と公共福祉の促進に貢献しています。ITLは、情報技術の開発と生産的利用を促進するため、試験、試験方法、参照データ、概念実証の実装、技術分析を開発しています。ITLの責務には、連邦政府の情報システムにおける国家安全保障関連情報以外の情報の費用対効果の高いセキュリティとプライバシーを確​​保するための、管理、運営、技術、および物理的な標準とガイドラインの開発が含まれます。特別出版物800シリーズは、ITLによる情報システムセキュリティに関する研究、ガイドライン、アウトリーチ活動、そして産業界、政府機関、学術機関との共同活動について報告しています。

概要

本勧告は、決定論的手法を用いた乱数ビット生成のメカニズムを規定する。提供される手法は、ハッシュ関数またはブロック暗号アルゴリズムのいずれかに基づいています。

キーワード

謝辞

米国国立標準技術研究所（NIST）は、本勧告の策定にご尽力いただいたNSAのマイク・ボイル氏とメアリー・ベイシュ氏に深く感謝申し上げます。また、NISTは官民両部門からの多大な貢献にも感謝申し上げます。

1 はじめに

本勧告は、暗号技術を用いるアプリケーションで乱数が必要な場合に、乱数ビットを直接生成したり、乱数に変換したりできる乱数ビットを生成する手法を規定する。

DRBGは、本勧告で規定されているDRBGメカニズムに基づいており、乱数源を含む。DRBGメカニズムは、乱数源の出力から決定されるシードによって決定される初期値からビット列を生成するアルゴリズム（すなわち、DRBGアルゴリズム）を使用する。シードが提供され、初期値が決定されると、DRBG はインスタンス化されたとみなされ、出力を生成するために使用できるようになります。プロセスの決定論的な性質のため、DRBG はランダムビットではなく疑似ランダムビットを生成すると言われます。DRBG をインスタンス化するために使用されるシードには、ランダム性を保証するために十分なエントロピーが含まれている必要があります。シードが秘密に保持され、アルゴリズムが適切に設計されている場合、DRBG によって出力されるビットは、インスタンス化された DRBG のセキュリティ強度まで予測不可能になります。

DRBG メカニズムを使用する RBG によって提供されるセキュリティは、システム実装の問題です。RBG が消費アプリケーションでの使用に適しているかどうかを判断する際には、DRBG メカニズムとそのランダム性ソースの両方を考慮する必要があります。

2 適合性試験

本勧告の実装に対する適合性試験は、暗号モジュール検証プログラム（CMVP）および暗号アルゴリズム検証プログラム（CAVP）の枠組み内で実施される。本勧告の要件は「しなければならない」という語で示されている。これらの要件の一部は、CMVPまたはCAVPの検証試験の範囲外となる場合があり、本勧告を組み込んだアプリケーションを使用、実装、インストール、または設定する主体の責任となる。

3 適用範囲

本勧告には以下が含まれます。

1. DRBGメカニズムの使用要件

2. ハッシュ関数とブロック暗号を使用するDRBGメカニズムの仕様

3. 実装上の問題

4. 保証に関する考慮事項

乱数生成は、2つのエンティティ間の相互運用性を必要としません。つまり、通信するエンティティは、通信能力に影響を与えることなく、異なるDRBGメカニズムを使用できます。したがって、エンティティは、使用するアプリケーションに適切な単一のDRBGメカニズムを選択できます。DRBGメカニズムの選択については、付録Cを参照してください。

乱数ビット生成器の正確な構造、設計、および開発については、本書の範囲外です。

4 用語と定義

table:用語と定義

Algorithm アルゴリズム 計算のための明確に指定された数学的プロセス。これに従えば規定の結

果が得られる一連の規則。

Approved 承認された FIPS承認、NIST推奨、および/または暗号アルゴリズム検証プログラム

（CAVP）による検証済み。

Backtracking Resistance バックトラッキング耐性 RBG が T 時刻以降のバックトラッキング耐性を提供するとは、T 時刻以

降の RBG の状態を知っている攻撃者 (ただし、RBG のセキュリティ強度

に匹敵する作業を実行できない) が、理想的なランダム ビット文字列の

観測と、T 時刻以前またはそれ以前に RBG によって出力される (以前に見

たことのない) ビット文字列の観測を区別できないことが保証される場合

です。特に、攻撃者が最初に侵害された RBG の状態から「バックトラッ

キング」して、以前の RBG の状態と対応する出力 (T 時刻における RBG

の状態と出力を含む) に関する知識を取得できるように設計された RBG

は、 T 時刻以降のバックトラッキング耐性を提供しません (予測耐性とは

対照的)。

Biased 偏った 標本空間から選択された値が、ある値が他の値よりも選ばれる可能性が高

い場合、その値が偏っていると言われます。「偏りがない」とは対照的で

す。

Bitstring ビット列 ビット列は 0 と 1 の順序付けられたシーケンスです。

Bitwise Exclusive-Or ビット排他的論理和 排他的論理和演算を使用して各ビット文字列の対応するビットを結合す

る、同じ長さの 2つのビット文字列に対する演算。

Block Cipher ブロック暗号 暗号鍵を用いて一度に1つの情報ブロックを変換する対称鍵暗号アルゴリ

ズム。ブロック暗号アルゴリズムでは、入力ブロックの長さは出力ブロッ

クの長さと同じになります。

Consuming Application 消費アプリケーション 承認された乱数ビット ジェネレータから取得した乱数またはビットを使

用するアプリケーション (ミドルウェアを含む)。

Cryptographic Key (Key) 暗号鍵（キー） 暗号関数の動作を決定するパラメータ。例：

1. 平文から暗号文への変換（およびその逆）、

2. 鍵素材の生成、

3. デジタル署名の計算または検証。

Deterministic Algorithm 決定論的アルゴリズム 同じ入力が与えられると、常に同じ出力を生成するアルゴリズム。

Deterministic Random 決定論的乱数 DRBGメカニズムを備え、（少なくとも初期段階では）乱数源にアクセス

できるRBG。

Bit Generator (DRBG) ビット生成器（DRBG） DRBGは、シードと呼ばれる秘密の初期値とその他の入力からビット列を

生成します。

DRBGは擬似乱数（またはビット）生成器と呼ばれることもあります。

NRBGとは対照的です。

DRBG Mechanism DRBGメカニズム RBG のインスタンス化とインスタンス化解除、疑似乱数ビットの生成、

(オプションで) RBG の再シード、および DRBG メカニズムの健全性のテ

ストに必要な機能を含む RBG の部分。

DRBG Mechanism Boundary DRBGメカニズム境界 DRBG メカニズムの動作と、他のプロセスとの相互作用および関係を説

明するために使用される概念的な境界。(min-entropy を参照)

Entropy エントロピ 閉鎖系における無秩序性、ランダム性、または変動性の尺度。本勧告では

最小エントロピーが用いられる。

Entropy Input エントロピー入力 DRBG メカニズムの予測不可能性について評価された最小量を提供する入

力ビット文字列。(min-entropy を参照。)

Entropy Source エントロピー源 ノイズ源（例：熱雑音やハードドライブのシーク時間）、ヘルステスト、

およびオプションのコンディショニングコンポーネントを組み合わせた

ものです。エントロピー源は、RBGで使用されるランダムビット列を生

成します。

Equivalent Process 同等のプロセス 同じ値が各プロセスに入力され、同じ出力が生成される場合、2 つのプロ

セスは同等です。

Exclusive-or 排他的論理和 数学演算。記号⊕は次のように定義されます。

0 ⊕ 0 = 0 1 ⊕ 0 = 1

0 ⊕ 1 = 1 1 ⊕ 1 = 0

繰り上がりなしの2進加算と同等です。

Fresh Entropy 新鮮なエントロピー 予測耐性を提供するために使用されているライブ エントロピー ソースに

アクセスできるエントロピー ソース、NRBG、または DRBG からのビット

文字列出力。

Full Entropy 完全エントロピー この勧告の目的上、完全エントロピー ビット文字列のソースは、同じ長

さの理想的なランダム ビット文字列のソースの実際的な近似として機能

します (理想的なランダム シーケンスを参照)。

Hash Function ハッシュ関数 大きな（場合によっては非常に大きな）定義域の値を、より狭い範囲に

マッピングする（数学的な）関数。この関数は以下の特性を満たす。

1. （一方向性）任意の入力を、事前に指定された出力にマッピングする

ことは、計算上不可能である。

2. （衝突なし）任意の2つの異なる入力を、同じ出力にマッピングする

ことは、計算上不可能である。

Health Testing 健康検査 通常操作の直前または通常操作中に実装内でテストを実行し、実装が実

装どおりに、検証どおりに動作し続けるかどうかを確認します。

Ideal Random Bitstring 理想的なランダムビット列 理想的なランダム シーケンスを参照。

(やや略)

6 文書構成

本勧告は、以下の構成となっています。

第7章では、DRBGメカニズムを使用するDRBGの機能モデルを示し、DRBGメカニズムの主要構成要素について説明します。

第8章では、DRBGメカニズムの実装と使用に関する概念と一般的な要件について説明します。

第9章では、第8章で導入されたDRBGメカニズムの機能を規定します。

これらの機能は、第10章で規定されているDRBGアルゴリズムを使用します。

第11章では、DRBGメカニズムの保証に関する課題（文書化要件、実装検証、および健全性テストを含む）を取り上げます。

本勧告には、以下の付録も含まれています。

付録Aでは、変換ルーチンを示します。

付録Cでは、DRBGメカニズムの選択について説明します。

付録Dでは、参考文献を示します。

付録Eでは、SP 800-90Aの初版発行以降の変更点の一覧を示します。

7 DRBGの機能モデル

図1: DRBG機能モデル

7.1 エントロピー入力

エントロピー入力は、乱数源を用いてシード（セクション8.6参照）を生成するためのDRBGメカニズムに提供されます。エントロピー入力とシードは秘密に保持されなければなりません。この情報の秘密性が、DRBGのセキュリティの基盤となります。少なくとも、乱数源はDRBGメカニズムが要求するセキュリティ強度をサポートする入力を提供しなければなりません。

適切な乱数源については、セクション8.6.5で説明します。

理想的には、エントロピー入力は完全なエントロピーを持つべきですが、DRBGメカニズムは、完全なエントロピーを持つ入力を必要としないように規定されています。これは、エントロピーの合計がDRBGメカニズムの要件を満たす限り、エントロピー入力の長さが必要なエントロピー（ビット単位で表現）よりも長くても許容することで実現されます。エントロピー入力は、固定長だけでなく、可変長（指定された制限内）にも定義できます。 DRBGメカニズムは、いずれの場合も、エントロピー入力が要求された際に、返されるビット文字列に少なくとも要求された量のエントロピーが含まれることを想定しています。要求された量を超えるエントロピーは必須ではありませんが、望ましいものです。

7.2 その他の入力

DRBGメカニズムは、入力としてその他の情報を取得する場合があります。この情報は、利用するアプリケーションによって秘密に保持される必要がある場合とそうでない場合があります。ただし、DRBG自体のセキュリティは、この情報の秘密性に依存しません。可能な場合は、情報の妥当性をチェックする必要があります。例えば、時刻を入力として使用する場合は、時刻の形式と妥当性をチェックできます。ほとんどの場合、インスタンス化時にノンスが必要です（セクション8.6.1および8.6.7を参照）。必要な場合、ノンスはエントロピー入力と組み合わされ、初期DRBGシードが作成されます。

DRBGインスタンス化時にはパーソナライゼーション文字列を使用する必要があります。パーソナライゼーション文字列を使用する場合、パーソナライゼーション文字列はエントロピー入力ビットと組み合わされ、場合によってはnonceも組み合わされて初期DRBGシードが作成されます。パーソナライゼーション文字列は、同じDRBGメカニズムタイプのすべてのインスタンス化（例：HMAC_DRBGのすべてのインスタンス化）で一意である必要があります。パーソナライゼーション文字列に関する詳細な説明は、セクション8.7.1を参照してください。

再シード時および疑似乱数ビットが要求された際にも、追加の入力が提供される場合があります。この入力に関する説明は、セクション8.7.2を参照してください。

7.3 内部状態

内部状態はDRBGのメモリであり、DRBGメカニズムが使用または操作するすべてのパラメータ、変数、およびその他の格納値で構成されます。内部状態には、管理データ（セキュリティ強度など）と、疑似乱数ビットの生成中に操作または変更されるデータ（つまり、動作状態）の両方が含まれます。

7.4 DRBGメカニズムの機能

DRBGメカニズムの機能は、DRBGの内部状態を処理します。本勧告におけるDRBGメカニズムには、5つの独立した機能があります。

1. インスタンス化機能は、エントロピー入力を取得し、それをnonceおよびパーソナライゼーション文字列と組み合わせて、初期内部状態を生成するシードを生成します。

2. 生成機能は、要求に応じて、現在の内部状態と、場合によっては追加の入力を使用して、疑似乱数ビットを生成します。また、次の要求のための新しい内部状態も生成されます。

3. 再シード機能は、新しいエントロピー入力を取得し、それを現在の内部状態および提供された追加の入力と組み合わせて、新しいシードと新しい内部状態を生成します。

4. インスタンス化解除機能は、内部状態をゼロ化（つまり消去）します。

5. ヘルステスト機能は、DRBGメカニズムが正常に機能し続けていることを確認します。

8. DRBGメカニズムの概念と一般要件

8.1 DRBGメカニズムの機能

DRBGメカニズムには、インスタンス化、インスタンス解除、生成、およびヘルステストの機能が必要です。DRBGメカニズムには、オプションで再シード機能が含まれます。DRBGは、DRBGによる出力の生成前にインスタンス化される必要があります。これらの機能は、セクション9で規定されています。

8.2 DRBGのインスタンス化

DRBGは、異なる目的（例：DSA秘密鍵とAES鍵）で擬似乱数ビットを取得するために使用でき、目的ごとに個別にインスタンス化できるため、実質的に2つのDRBGを作成できます。

DRBGはシードを使用してインスタンス化され、シードを再設定することができます。シードを再設定する場合、シードはインスタンス化に使用したシードとは異なる必要があります。各シードは、DRBGインスタンス化のシード期間を定義します。インスタンス化は、新しいシードが取得されたときに始まり、次のシードが取得されるか、DRBGが使用されなくなったときに終了する1つ以上のシード期間で構成されます（図2を参照）。

図2: DRBGのインスタンス化

8.3 内部状態

インスタンス化の際、シードから初期内部状態が導出されます。インスタンス化の内部状態には、以下のものが含まれます。

1. 動作状態：

a. シードから導出され、内部状態の一部となる1つ以上の値。これらの値は秘密に保持されます。

b. インスタンス化のシードまたは再シード以降に生成されたリクエストの数。

2. 管理情報（例：セキュリティ強度、予測耐性フラグ）。

内部状態は、少なくとも、利用アプリケーションによって要求された疑似乱数出力ビットの意図された用途と同等に保護されなければなりません。DRBGメカニズムの実装は、複数のインスタンス化を処理するように設計できます。各DRBGインスタンス化は、独自の内部状態を持つ必要があります。あるDRBGインスタンス化の内部状態を、別のインスタンス化の内部状態として使用してはいけません。

8.4 インスタンス化によってサポートされるセキュリティ強度

本勧告で規定されるDRBGメカニズムは、112ビット、128ビット、192ビット、または256ビットの4つのセキュリティ強度をサポートします。インスタンス化のセキュリティ強度はDRBGのインスタンス化中に要求され、インスタンス化関数は要求されたセキュリティ強度に適したエントロピー量を取得します。各DRBGメカニズムは、その設計に基づき、サポートできるセキュリティ強度に制限があります（セクション10を参照）。

特定のインスタンス化によってサポートされる実際のセキュリティ強度は、DRBGの実装と、インスタンス化関数に提供されるエントロピー量に依存します。特定のインスタンス化によって実際にサポートされるセキュリティ強度は、そのDRBG実装で可能な最大セキュリティ強度よりも低い場合があることに注意してください（表1を参照）。たとえば、最大 256 ビットのセキュリティ強度をサポートするように設計された DRBG は、256 ビットのセキュリティ強度によって提供される追加のセキュリティが必要ない場合、代わりに 128 ビットのセキュリティ強度のみをサポートするようにインスタンス化できます (たとえば、インスタンス化中に 256 ビットのエントロピーではなく 128 ビットのエントロピーのみを要求するなど)。

table::表1: 考えられるセキュリティ強度の例

最大設計セキュリティ強度 112 128 192 256

考えられるセキュリティ強度 112 112, 128 112, 128, 192 112, 128, 192, 256

インスタンス化に続いて、生成関数に疑似乱数ビットの要求を行うことができます (セクション 9.3 を参照)。DRBG から返される疑似乱数ビットは、DRBG がインスタンス化されてサポートするよりも高いセキュリティ強度を必要とするアプリケーションには使用しないでください。返されるビットで提供されるセキュリティ強度は、DRBG がサポートするセキュリティ強度と返されるビット文字列の長さの小さい方です。つまり、Security_strength_of_output = min(output_length, DRBG_security_strength) です。

各生成要求に対して、ビットに提供されるセキュリティ強度が要求されます。生成関数の呼び出し中に、インスタンス化のセキュリティ強度まで任意のセキュリティ強度を要求できます。例えば、インスタンス化は 128 ビットのセキュリティ強度でインスタンス化できますが、疑似乱数ビットの要求は、ビットを生成するために実際にはより低いセキュリティ強度が必要であることを示している可能性があります。要求が有効であると仮定すると、要求されたビット数が返されます。

インスタンス化が複数の目的で使用される場合、各目的の最小セキュリティ強度要件を考慮する必要があります。DRBG は、必要な最高のセキュリティ強度でインスタンス化する必要があります。例えば、ある目的で 112 ビットのセキュリティ強度が必要であり、別の目的で 256 ビットのセキュリティ強度が必要な場合、DRBG は 256 ビットのセキュリティ強度をサポートするようにインスタンス化する必要があります。

8.5 DRBGメカニズム境界

便宜上、本勧告では「DRBGメカニズム境界」という概念を用いて、DRBGメカニズムの動作、および他のプロセスとの相互作用と関係を説明します。DRBGメカニズム境界には、DRBGに必要なすべてのDRBGメカニズム機能と内部状態が含まれます。データは、DRBGの公開インタフェースを介してDRBGメカニズム境界に入り、これらのインタフェースは、利用アプリケーションで利用可能になります。

DRBGメカニズム境界内では、

1. DRBGの内部状態とDRBGメカニズム機能の動作は、DRBGメカニズム仕様に従ってのみ影響を受けるものとします。

2. DRBGの内部状態は、DRBGメカニズム境界内にのみ存在するものとします。内部状態は、DRBG以外の機能、またはそのDRBGもしくは他のDRBGのインスタンス化からはアクセスできないものとする。

3. DRBG内部状態の秘密部分に関する情報、およびこれらの秘密部分を含む計算における中間値は、DRBG疑似乱数ビット出力について規定されている場合を除き、DRBGメカニズム境界を越えるいかなる情報にも影響を与えないものとする。

各DRBGメカニズムには、1つ以上の暗号プリミティブ（ハッシュ関数またはブロック暗号アルゴリズム）が含まれる。他のアプリケーションが同じ暗号プリミティブを使用することはできるが、DRBGの内部状態およびDRBGメカニズム機能は、これらの他のアプリケーションの影響を受けないものとする。例えば、DRBGメカニズムは、デジタル署名アプリケーションと同じハッシュ関数コードを使用することができる。

図3: 単一デバイス内のDRBGメカニズムの機能

分散型DRBGメカニズム機能の使用は、DRBGの主な用途がインスタンス化機能や再シード機能の繰り返し使用を必要としない制限された環境（スマートカードアプリケーションなど）では便利な場合があります。

各DRBGメカニズム境界またはサブ境界には、その境界内の他のDRBGメカニズム機能の「健全性」をテストするための健全性テスト機能が含まれていなければなりません。さらに、インスタンス化関数を含む境界またはサブ境界には、インスタンス化を終了するためのインスタンス化解除関数を含める必要があります。

図4: 分散DRBGメカニズムの機能

DRBGメカニズム機能が分散されている場合、分散DRBGメカニズムのサブ境界間で転送される内部状態または内部状態の一部の機密性と整合性を保護するために、物理的または暗号的にセキュアなチャネルが使用されなければならない。

セキュアチャネルによって提供されるセキュリティは、利用アプリケーションが要求するセキュリティと整合していなければならない。セキュアチャネルのより詳細な定義については、セクション4を参照のこと。

分散DRBGの場合、各サブ境界は暗号モジュール境界と同じであるか、または完全にその境界内に包含される。

8.6 シード

DRBGを用いて擬似乱数ビットを生成する場合、DRBGによる出力ビットの生成前にシードを取得しなければならない。シードはDRBGをインスタンス化し、DRBGを呼び出して最初の出力ビットを取得する際に使用する初期内部状態を決定するために使用される。

シードの再生成は、シードまたは内部状態が既知となった場合に、DRBG出力の機密性を回復する手段である。定期的なシードの再生成は、DRBGシード、エントロピー入力、または動作状態のいずれかが時間の経過とともに漏洩する脅威に対処するための優れた方法である。一部の実装（例：スマートカード）では、適切なシード再生成プロセスが不可能な場合がある。このような場合、最善策はDRBGを交換し、その過程で新しいシードを取得する（例：新しいスマートカードを入手する）ことである。

シードおよびDRBGメカニズムによるシードの使用は、以下のサブセクションで規定されているように生成および処理されなければならない。

8.6.1 インスタンス化のためのシード構築

図5は、インスタンス化のためのシード構築プロセスを示しています。インスタンス化のためのシードを決定するために使用されるシード素材は、乱数源からのエントロピー入力、ノンス、およびオプション（ただし推奨）のパーソナライゼーション文字列で構成されます。

エントロピー入力は、シードの構築に常に使用されなければなりません。エントロピー入力の要件については、セクション8.6.3で説明します。

下記の場合を除き、ノンスを使用する必要があります。ノンスの要件については、セクション8.6.7で説明します。パーソナライゼーション文字列も使用する必要があります。パーソナライゼーション文字列の要件については、セクション8.7.1で説明します。

図5: インスタンス化のためのシード構築

DRBGメカニズムと乱数源によっては、シード素材からシードを導出するために導出関数が必要になる場合があります。ただし、特定の状況では、ブロック暗号アルゴリズムに基づくCTR_DRBGメカニズム（セクション10.2を参照）は、導出関数なしで実装できます。この方法で実装した場合、（図5に示すような）（別途）ノンスは使用されません。ただし、必要に応じてパーソナライゼーション文字列にノンスを含めることも可能です。

8.6.2 再シードのためのシード構築

図6は、インスタンスの再シードのためのシード構築プロセスを示しています。再シードのためのシードは、内部状態3に格納される値、新しいエントロピー入力、そしてオプションの追加入力で構成されます。内部状態値とエントロピー入力は必須です。

エントロピー入力の要件については、8.6.3節で説明します。追加入力の要件については、8.7.2節で説明します。8.6.1節と同様に、再シードには導出関数が必要になる場合があります。

図6: 再シードのためのシード構築

8.6.3 エントロピー入力のエントロピー要件

エントロピー入力は、インスタンス化のセキュリティ強度と同等かそれ以上のエントロピーを持つ必要があります。追加のエントロピーは、インスタンス化中にノンスまたはオプションのパーソナライゼーション文字列で、あるいは再シードおよび生成中に追加入力で提供される場合がありますが、これは必須ではなく、内部状態に記録されるDRBGインスタンス化の「公式」セキュリティ強度を高めるものではありません。最小値よりも多くのエントロピーを使用することで、セキュリティの「クッション」が提供されます。これは、エントロピー入力で提供されるエントロピーの評価が正しくない場合に役立つ可能性があります。評価された量よりも多くのエントロピーを持つことは許容されますが、評価された量よりも少ないエントロピーを持つことは、セキュリティにとって致命的となる可能性があります。特にインスタンス化中に、必要以上のエントロピーが存在する場合、最小要求エントロピーよりも高いレベルの保証が提供されます。

8.6.4 シード長

シードの最小長は、DRBGメカニズムと、それを利用するアプリケーションに必要なセキュリティ強度に依存しますが、必要なエントロピービット数以上である必要があります。セクション10の表を参照してください。

8.6.5 乱数源

8.6.6 エントロピー入力とシードのプライバシー

エントロピー入力とその結果生成されるシードは、利用アプリケーションによって保護されるデータに要求されるセキュリティと整合した方法で処理されなければならない。例えば、DRBGを用いて鍵を生成する場合、鍵を生成するために使用されるエントロピー入力とシードは（少なくとも）鍵と同じセキュリティ強度で保護されなければならない。

DRBGのセキュリティは、エントロピー入力の機密性に依存する。このため、暗号モジュールの検証においては、エントロピー入力は重要なセキュリティパラメータ（CSP）として扱われなければならない。エントロピー入力を必要とするDRBG機能のエントロピー入力は、その機能を含む暗号モジュール内から取得するか、別の暗号モジュールから取得し、安全なチャネルを介してDRBG機能の暗号モジュールに転送しなければならない。

8.6.7 nonce

特定の攻撃をブロックするためのセキュリティクッションを提供するために、インスタンス化中のシード構築時に nonce が必要となる場合があります。 nonce は次のいずれかでなければなりません。

a. 少なくとも (security_strength/2) ビットのエントロピーを持つ値、または

b. (security_strength/2) ビットのランダム文字列が繰り返される頻度を超えないと予想される値。

各 nonce は、インスタンス化が実行される暗号モジュールごとに一意でなければなりませんが、秘密である必要はありません。nonce を使用する場合、重要なセキュリティパラメータとみなされます。

nonce は、以下のコンポーネントの 1 つ（または複数）で構成できます（他のコンポーネントも適切な場合があります）。

1. 承認されたランダムビット生成器を用いて、各nonceごとに新たに生成されるランダム値。

2. 使用されるたびに異なるように十分な解像度（詳細度）を持つタイムスタンプ。

3. 単調増加するシーケンス番号、または

4. タイムスタンプと単調増加するシーケンス番号の組み合わせ。シーケンス番号は、タイムスタンプが変更された場合にのみリセットされます。例えば、タイムスタンプは日付は表示しますが時刻は表示しない場合は、特定の日に繰り返されないシーケンス番号が追加されます。

上記のケース1の場合、乱数はエントロピー入力と同じソースから、同じ時刻に取得できます。この場合、シードは「非常に強い」エントロピー入力とオプションのパーソナライゼーション文字列から構築されていると見なすことができます。この場合、エントロピー入力のエントロピーは(3/2 security_strength)ビット以上です。

上記のケース2の場合、タイムスタンプは信頼されている必要があります。信頼できるタイムスタンプは、正確な時刻情報を提供できると信頼されているエンティティによって生成および署名されます。

ノンスは、DRBGが利用アプリケーションにsecurity_strengthビットのセキュリティを提供することをより確実にします。 DRBGがノンスなしで何度もインスタンス化されると、侵害の可能性が高くなる可能性があります。一部の利用アプリケーションでは、DRBGの1回の侵害で長期的な秘密が漏洩する可能性があります（例：DSAメッセージごとの秘密が漏洩すると、署名鍵が漏洩する可能性があります）。

8.6.8 再シード

シード（およびその他の入力情報）から生成される出力が多すぎると、将来の出力を正しく予測するのに十分な情報が得られる可能性があります（セクション8.8を参照）。定期的な再シードはセキュリティリスクを軽減し、DRBGを使用する暗号メカニズムによって保護されているデータが侵害される可能性を低減します。

シードには有限のシードライフ（つまり、シード期間中に生成される出力の数）があり、最大シードライフは使用するDRBGメカニズムに依存します。実装は、使用するDRBGメカニズムに指定されたシードライフの制限、または実装者が選択したより厳しい制限を適用する必要があります。DRBGの最大シードライフに達した場合、DRBGは再シードされるまで出力を生成してはなりません。

再シードは、1) 利用アプリケーションによる DRBG の明示的な再シード、2) 予測耐性が要求された場合の generate 関数による再シード（セクション 8.8 参照）、または 3) generate 関数の実行中にシードの有効期限の終了が決定された場合（セクション 9.3.1 参照）、のいずれかで実行されます。

DRBG の再シードは、特定の DRBG メカニズムの仕様に従って実行されるものとします。本勧告における DRBG 再シード仕様は、古いシードと新たに取得したエントロピー入力の両方によって決定され、必要なセキュリティ強度をサポートする新しいシードを生成するように設計されています。

再シードの代わりに、全く新しいインスタンスを作成することもできます。ただし、新しいインスタンスを作成するよりも再シードの方が優先されます。DRBG インスタンスが最初に十分なエントロピーでシードされ、その後、乱数源が検出されずに失敗した場合、同じ（失敗した）乱数源を使用した新しいインスタンスは、安全に動作するために十分なエントロピーを持たないことになります。ただし、すでに適切にシードされている DRBG インスタンスの乱数ソースに検出されない障害がある場合、再シード操作で新しいエントロピーを導入できなかったときに、DRBG インスタンスは以前のエントロピーを保持し続けます。

8.6.9 シードの使用

DRBGのインスタンス化の初期化に使用されたシードは、同じインスタンス化の再シードに意図的に使用したり、別のDRBGインスタンス化のシードとして使用したりしてはなりません。また、DRBGインスタンス化は、自身を再シードしてはなりません。DRBGは、シードが利用可能になり、内部状態が初期化されるまで出力を生成しないことに注意してください（セクション10を参照）。

8.6.10 エントロピー入力とシードの分離

DRBGで使用されるシード、およびそのシードを生成するために使用されるエントロピー入力は、他の目的（例：ドメインパラメータや素数生成）に意図的に使用してはなりません。

8.7 DRBGメカニズムへのその他の入力

DRBGのインスタンス化、生成、および再シード中に、その他の入力が提供される場合があります。この入力にはエントロピーが含まれていても構いませんが、必須ではありません。インスタンス化の際には、パーソナライゼーション文字列が提供され、エントロピー入力およびノンスと組み合わせてシードが導出される（セクション8.6.1を参照）。

疑似乱数ビットが要求され、再シードが実行される場合、追加の入力が提供される場合がある（セクション8.7.2を参照）。

入力を取得する方法によっては、入力の正確な値がユーザーまたは消費アプリケーションに既知である場合とそうでない場合がある。例えば、入力はユーザーまたは消費アプリケーションによって入力された値から直接導出されるか、ユーザーまたは消費アプリケーションによって導入された情報（例えば、キーストロークに基づくタイミング統計）から導出されるか、あるいは別のRBGの出力が入力となる場合がある。

8.7.1 パーソナライゼーション文字列

パーソナライゼーション文字列は、インスタンス化関数へのオプション（ただし推奨）の入力であり、シードの導出に使用されます（セクション8.6.1を参照）。パーソナライゼーション文字列は、暗号モジュールの内部または外部から取得でき、空文字列にすることもできます。DRBGは、パーソナライゼーション文字列にエントロピーが提供される場合でも、エントロピーの提供にパーソナライゼーション文字列に依存しないことに注意してください。また、エントロピー入力が不明である限り、攻撃者がパーソナライゼーション文字列を知っていても、DRBGインスタンス化のセキュリティ強度は低下しません。

暗号モジュール内で使用される場合、パーソナライゼーション文字列は重要なセキュリティパラメータとは見なされません。

パーソナライゼーション文字列には秘密情報が含まれる場合がありますが、インスタンス化されるDRBGがサポートするセキュリティ強度よりも高いセキュリティ強度での保護を必要とする秘密情報は含まれてはなりません。例えば、112ビットのセキュリティ強度でDRBGをインスタンス化するために使用するパーソナライゼーション文字列には、128ビットの保護を必要とする情報を含めてはなりません。DRBGの実装によっては、パーソナライゼーション文字列の使用をサポートしている場合もありますが、必ずしもそうする必要はありません。

パーソナライゼーション文字列の目的は、DRBGのインスタンス化に追加の入力情報を導入することです。このパーソナライゼーション文字列には、攻撃者に知られていない値、またはこのDRBGインスタンスを他のすべてのインスタンスと区別する値が含まれる場合があります。理想的には、パーソナライゼーション文字列は可能な限り一意のビット文字列に設定されます。パーソナライゼーション文字列の内容の適切な情報源としては、以下が挙げられます。

• アプリケーション識別子、• この特定のDRBGインスタンスの特別なキー値

• デバイスのシリアル番号、DRBGインスタンス、

• ユーザーID、• プロトコルバージョン識別子、

• モジュールごとまたはデバイスごとの値、• 乱数、

• タイムスタンプ、• ノンス、および

• ネットワークアドレス、• 他の承認済みまたは未承認の乱数ビット生成器からの出力。

8.7.2 追加入力

リクエスト中に、再シード関数および生成関数にオプションで追加入力が提供される場合があります。追加入力は暗号モジュールの内部または外部から取得され、秘密情報または公開情報が含まれる場合があります。DRBGは、追加入力にエントロピーが提供される可能性はあるものの、エントロピーの提供をその追加入力に依存しないこと、また、攻撃者が追加入力を知ってもDRBGのセキュリティ強度が低下することはないことに注意してください。ただし、追加入力に秘密情報／個人情報（社会保障番号など）が含まれる場合、その情報はDRBGがサポートするセキュリティ強度よりも高いセキュリティ強度で保護する必要はありません。DRBGの特定の実装には追加入力を含めることができますが、必須ではありません。暗号モジュール内で使用される場合、DRBGリクエストで使用される追加入力は、追加入力に含まれる秘密情報が重要なセキュリティパラメータとして適格でない限り、重要なセキュリティパラメータとは見なされません。

追加入力は、DRBG とそれを使用するアプリケーションの両方にとってオプションであり、実装には追加入力を入力する機能が含まれている場合と含まれていない場合があります。追加入力の値は、秘密にすることも公開することもできます。その値は任意ですが、実装と DRBG メカニズムに応じて長さが制限される場合があります。追加入力の使用は、DRBG 内部状態にエントロピーを追加することで、エントロピー要件が満たされていることの保証を高める手段となる場合があります。追加入力が秘密に保持され、十分なエントロピーがある場合、エントロピー入力、シード、または 1 つ以上の DRBG 内部状態の侵害から回復する際に、その入力によってより高い保証を提供できます。

8.8 予測耐性とバックトラッキング耐性

図7は、与えられたシードから生成されるDRBG内部状態のシーケンスを示しています。各内部状態のビットの一部は、ユーザーの要求に応じて疑似乱数ビットを生成するために使用されます。以下の説明では、この図を用いてバックトラッキング耐性と予測耐性について説明します。

Statexに秘密情報と非秘密情報の両方が含まれている状態で、Statexで侵害が発生したと仮定します。

図7: DRBG状態のシーケンス

バックトラッキング耐性: バックトラッキング耐性は、時間 T 以降のいずれかの時点で DRBG の内部状態を知っている攻撃者が、理想的なランダム ビット文字列の観測と、時間 T より前に DRBG によって出力された (以前に見たことのない) ビット文字列の観測を区別できないことが保証されている場合、時間 T に対して提供されます。これは、攻撃者が DRBG の主張するセキュリティ強度を無効にするために必要な作業を実行できないことを前提としています。バックトラッキング耐性とは、DRBG の内部状態の侵害が以前の出力のセキュリティに影響を与えないことを意味します。つまり、以前の出力シーケンスのすべてにアクセスできる攻撃者は、インスタンス化のセキュリティ強度に関連付けられているよりも少ない作業で、それをランダム出力と区別することはできません。攻撃者が以前の出力の一部しか知らない場合、攻撃者は、その以前の出力シーケンスのうち、まだ見たことのないビットを 50/50 以上の確率で特定することはできません。

たとえば、攻撃者が Statex を知っているとします。バックトラッキング耐性とは、以下のことを意味します。

a. State1 から Statex-1 への出力ビットがランダム出力と区別できないこと、および b. Statex 内の秘密情報を知っていても、以前の内部状態値（State1 から Statex-1）自体を復元できないこと。

バックトラッキング耐性は、DRBG 生成アルゴリズムが一方向性関数であることを保証することで実現できます。本勧告におけるすべての DRBG メカニズムは、バックトラッキング耐性を提供するように設計されています。

予測耐性：予測耐性とは、DRBG 内部状態の侵害が将来の DRBG 出力のセキュリティに影響を与えないことを意味します。つまり、侵害後に出力シーケンスのすべてにアクセスできる攻撃者は、インスタンス化のセキュリティ強度に関連付けられているよりも少ない作業で、それをランダム出力と区別することはできません。攻撃者が将来の出力シーケンスの一部しか知らない場合、その将来の出力シーケンスのうち、既に知っているビット以外は（50/50 以上の確率で）予測することはできません。

例えば、攻撃者が Statex を知っているとします。予測耐性とは、以下のことを意味します。

a. Statex+1以降の出力ビットは、攻撃者が理想的なランダムビット列と区別できないこと。

b. Statexに関する知識がある場合、将来の内部状態値自体（Statex+1以降）は（50/50以上の確率で）予測できないこと。

予測耐性は、T より前のいずれかの時点における RBG の状態を知っている (ただし、RBG の主張するセキュリティ強度に一致する作業を実行できない) 攻撃者が、理想的なランダム ビット文字列の観測と、T 時点以降に RBG によって出力される (以前に見たことのない) ビット文字列の観測を区別できないことが確実な場合に、時間 T に対して提供されます。特に、攻撃者が最初に侵害された RBG 状態から前進して、後続の RBG 状態と対応する出力 (時間 T における RBG の状態と出力を含む) に関する知識を取得できるような設計の RBG では、時間 T に対して予測耐性は提供されません。

予測耐性は、連続する DRBG 要求の出力を生成する間に、DRBG が新しいエントロピーで効果的に再シードされることを保証することによってのみ提供できます。つまり、再シードされる DRBG のセキュリティ強度をサポートするのに十分な量のエントロピー (つまり、少なくともセキュリティ強度と同等の量) が、現在の DRBG 内部状態に関する情報によって攻撃者が将来の DRBG 内部状態または出力に関する有用な情報を得ることができないような方法で、DRBG に提供される必要があります。予測耐性は、乱数源がエントロピー源または NRBG に直接的または間接的にアクセスできる場合に提供できます (セクション 8.6.5 を参照)。

例えば、攻撃者が内部 Statex-2 を知っているとします (図 7 を参照)。攻撃者が使用されている DRBG メカニズムも知っている場合、Statex-1 と Statex を計算するのに十分な情報が得られます。その後、DRBGから出力される次のビットの予測が要求された場合、Statex+1が生成される前に、DRBGインスタンスに新しいエントロピービットが挿入され、StatexとStatex+1が分離されます。つまり、攻撃者はStatexを知るだけではStatex+1を計算できなくなります。予測要求中に挿入されたエントロピーによって、必要な作業量が大幅に増加します。

9 DRBGメカニズムの機能

本文書では、すべてのDRBGメカニズムとアルゴリズムを擬似コードで記述しています。これは機能を説明することを目的としています。擬似コードは、実際の実装を制限するものではありません。

11.3節で説明するヘルステスト機能を除き、本勧告におけるDRBGメカニズムの機能は、アルゴリズムとそのアルゴリズムを囲む擬似コードの「エンベロープ」として規定されています。各エンベロープ（本節で提供）内の擬似コードは、入力パラメータをチェックし、入力パラメータで提供されていない入力を取得し、適切なDRBGアルゴリズムにアクセスし、内部状態を管理します。関数は必ずしもこのようなエンベロープを使用して実装する必要はありませんが、同等の機能を持つものとします。

インスタンス化および再シード処理（9.1節および9.2節参照）では、8.6.1節および8.6.2節で説明するように、シードを構築するためにエントロピー入力と（通常は）ノンスが取得されます。本勧告の仕様では、この目的のためにGet_entropy_input関数が用いられる。

Get_entropy_input：エントロピー入力を取得するために使用される関数。関数呼び出しは以下のとおりである。

(status, entropy_input) = Get_entropy_input (min_entropy, min_length, max_length, prediction_resistance_request)

これは、少なくともmin_entropyビットのエントロピーを持つビット列(entropy_input)を要求する。文字列の長さは min_length ビット以上、max_length ビット以下でなければなりません。prediction_resistance_request パラメータは、要求時に予測耐性が提供されるかどうか（すなわち、新たなエントロピーが必要かどうか4）を示します。関数からはステータスコードが返されます。

実装では、パラメータの一部を省略することで、この機能を異なる方法で定義することもできます。例えば、多くの DRBG メカニズムでは、Get_entropy_input 関数の min_length = min_entropy ですが、この場合、2 番目のパラメータは省略できます。

このセクションの擬似コードでは、ERROR_FLAG と CATASTROPHIC_ERROR_FLAG の 2 つのクラスのエラーコードが返されます。これらのエラーコードの処理については、セクション 11.4 で説明します。実際には、エラーコードはエラーの理由に関する情報を提供する場合があります。

例えば、入力パラメータが正しくないために ERROR_FLAG が返された場合、ERROR_FLAG が問題を示している可能性があります。

利用側アプリケーションは、DRBG関数から返されるステータスを確認し、リクエストが成功したかどうか、または改善措置が必要かどうかを判断する必要があります。例えば、instantiate関数がエラーを返した場合、インスタンス化は作成されず、無効なstate_handleが返されます（セクション9.1を参照）。ただし、後続のreseedまたはgenerateリクエストでは、state_handleが存在しないことが検出されます。reseed関数がエラーを返した場合（セクション9.2を参照）、指定されたインスタンス化は再シードされていません（つまり、内部状態に新しいエントロピーが注入されていません）。generate関数がエラーを返した場合、出力文字列としてnull文字列が返され（セクション9.3.1を参照）、擬似乱数出力として使用してはなりません。

本勧告の擬似コードには、多くの場合コメントが含まれます。擬似コードを含む行に配置されたコメントはその行に適用されます。擬似コードを含まない行に配置されたコメントは、そのコメントのすぐ下の1行以上の擬似コードに適用されます。

9.1 DRBGのインスタンス化

DRBGは、擬似乱数ビットを生成する前にインスタンス化されるものとする。インスタンス化関数は、以下の処理を行う。

1. 入力パラメータの妥当性を確認する。

2. DRBGインスタンス化のセキュリティ強度を決定する。

3. セキュリティ強度をサポートするのに十分なエントロピーを持つエントロピー入力を取得する。

4. nonceを取得する（必要な場合）。

5. インスタンス化アルゴリズムを用いて初期内部状態を決定する。

6. 実装が同一のDRBGの複数の同時インスタンス化をサポートする場合、内部状態のstate_handleが利用アプリケーションに返される（下記参照）。

、DRBG メカニズムの適切なインスタンス化アルゴリズムへの呼び出しとします（セクション 10 を参照）。

1. requested_instantiation_security_strength: インスタンス化に必要なセキュリティ強度。1 つのセキュリティ強度のみをサポートする実装では、このパラメータは不要です。ただし、その実装を使用するすべての消費アプリケーションは、サポートされるセキュリティ強度を認識しておく必要があります。

2. prediction_resistance_flag: 疑似乱数ビットの 1 回以上の要求時に、消費アプリケーションが予測耐性を必要とするかどうかを示します。常に予測耐性を提供するか、またはサポートしない実装では、その意図が暗黙的にわかっている場合、このパラメータをサポートする必要はありません。ただし、消費アプリケーションのユーザーは、そのような実装を使用することを選択する前に、消費アプリケーションが予測耐性を必要とするかどうかを判断する必要があります。 prediction_resistance_flag が不要（つまり、予測耐性が常に実行されるか、サポートされていないことが分かっている）の場合、prediction_resistance_flag 入力パラメータとインスタンス化プロセスのステップ 2 は省略され、インスタンス化プロセスのステップ 11 では、prediction_resistance_flag は内部状態から省略されます。さらに、実装でこのフラグが使用されていない場合は、ステップ 6 を変更して、prediction_resistance_flag のチェックを行わないようにすることができます。この場合、Get_entropy_input 呼び出しに prediction_resistance_request パラメータを含める必要はありません。

3. personalization_string: パーソナライゼーション情報を提供するオプションの入力（セクション 8.6.1 および 8.7.1 を参照）。パーソナライゼーション文字列の最大長（max_personalization_string_length）は実装に依存しますが、特定の DRBG メカニズムに指定された最大長以下でなければなりません（セクション 10 を参照）。パーソナライズ文字列の入力がサポートされていない場合は、personalization_string 入力パラメータとインスタンス化プロセスのステップ 3 が省略され、インスタンス化プロセスのステップ 9 が変更されてパーソナライズ文字列が省略されます。

1. entropy_input: エントロピーを含む入力ビット。entropy_inputの最大長は実装依存であるが、選択されたDRBGメカニズムに指定された最大長以下でなければならない（セクション10を参照）。

2. nonce: セクション8.6.7で規定されるノンス。ノンスにランダム値が使用される場合、entropy_inputとノンスのランダム部分は、1回のGet_entropy_input呼び出しで取得できる点に留意する（インスタンス化プロセスのステップ6を参照）。この場合、Get_entropy_input 呼び出しの最初のパラメータは、ノンスのエントロピーを含めるように調整されます（つまり、security_strength は少なくとも security_strength の 1/2 だけ増加し、min-length はノンスの長さに合わせて増加されます）。インスタンス化プロセスのステップ 8 は省略され、インスタンス化プロセスのステップ 9 のパラメータリストからノンスは省略されます。

DRBG メカニズムではノンスが使用されない場合もあることに注意してください。この場合、ステップ 8 は省略され、インスタンス化プロセスのステップ 9 のパラメータリストからノンスは省略されます。

1. status：インスタンス化関数から返されるステータス。SUCCESS 以外のステータスが返された場合、消費アプリケーションには state_handle が返されないか、無効な state_handle が返されます。消費アプリケーションは、DRBG が正しくインスタンス化されたことを確認するために、ステータスを確認する必要があります。

2. state_handle: 後続の generate、reseed、uninstantiate、および health test 関数の呼び出しにおいて、このインスタンス化の内部状態を識別するために使用されます。実装が複数のインスタンス化を同時にサポートしていないため、状態ハンドルが不要な場合は、state_handle を返す必要はありません。この場合、インスタンス化プロセスステップ10は省略され、プロセスステップ11は内部状態のみを保存するように修正され、プロセスステップ12は state_handle を省略するように変更されます。

インスタンス化後に DRBG メカニズム境界内に保持される情報:

DRBG の内部状態。working_state と管理情報が含まれます (working_state と管理情報の定義については、セクション 8.3 と 10 を参照してください)。

インスタンス化プロセス:

コメント: 入力パラメータの妥当性を確認します。

1. requested_instantiation_security_strength > fastest_supported_security_strength の場合、(ERROR_FLAG, Invalid) を返します。

2. prediction_resistance_flag が設定されており、予測耐性がサポートされていない場合は、(ERROR_FLAG, Invalid) を返します。

3. personalization_string の長さ > max_personalization_string_length の場合、(ERROR_FLAG, Invalid) を返します。

4. security_strength を、{112, 128, 192, 256} の中から、requested_instantiation_security_strength 以上の最も低いセキュリティ強度に設定します。

5. ヌルステップ。

コメント: このヌルステップは、ステップ番号を変更せずに、SP 800-90 のオリジナルバージョンのステップを置き換えます。

コメント: エントロピー入力を取得します。

6. (status, entropy_input) = Get_entropy_input (security_strength, min_length, max_length, prediction_resistance_request)。

7. (status ≠ SUCCESS)の場合、(status, Invalid)を返します。

8. nonceを取得します。コメント: このステップには、nonceの妥当性に関する適切なチェックを含める必要があります。セクション8.6.7を参照してください。

コメント: 初期のworking_stateの値を取得するには、セクション10の適切なインスタンス化アルゴリズムを呼び出します。

9. initial_working_state = Instantiate_algorithm (entropy_input, nonce, personalization_string, security_strength).

10. 現在空の内部状態に対応する state_handle を取得します。空の内部状態が見つからない場合は、(ERROR_FLAG, Invalid) を返します。

11. 新しいインスタンスの内部状態（例えば、state_handleで示される値）を内部状態の初期値（つまり、working_stateをステップ9でinitial_working_stateとして返された値に設定する）とworking_stateに必要なその他の値（セクション10を参照）に設定し、管理情報を適切な値（例えば、security_strengthとprediction_resistance_flagの値）に設定します。

12. (SUCCESS, state_handle)を返します。

9.2 DRBGインスタンスの再シード

インスタンスの再シードは必須ではありませんが、利用側アプリケーションと実装がこの処理を実行できる場合は常に推奨されます。再シードにより、擬似乱数ビットの生成にエントロピーが追加されます。再シードは、次のいずれかの方法で実行されます。

利用側アプリケーションによって明示的に要求される。

利用側アプリケーションによって予測耐性が要求されたときに実行される。

指定数の擬似乱数出力が生成されたとき、または指定数の生成要求が行われたときに（つまり、シードライフの終了時に）、生成関数によってトリガーされる。

外部イベントによってトリガーされる（例：エントロピーが利用可能なとき）。

再シード関数は、以下の処理を実行します。

1. 入力パラメータの妥当性を確認します。

2. DRBGのセキュリティ強度をサポートする乱数源からエントロピー入力を取得します。

3. 再シードアルゴリズムを使用して、現在の動作状態と新しいエントロピー入力、および追加の入力を組み合わせて、新しい動作状態を決定します。

working_state を特定のDRBGインスタンス（例：HMAC_DRBG）の動作状態とし、min_length と max_length を各DRBGメカニズムに対して定義します。Reseed_algorithm をDRBGメカニズムに適切な再シードアルゴリズムの呼び出しとします。（セクション10を参照）。

DRBGインスタンスの再シードには、以下の手順または同等の手順を使用します。

Reseed_function (state_handle, prediction_resistance_request, additional_input):

1) state_handle: 再シードする内部状態を示すポインタまたはインデックス。実装が複数のインスタンス化を同時にサポートしていないため、状態ハンドルが使用されていない場合、state_handleは入力として提供されません。この場合、内部状態は1つだけなので、再シード処理ステップ1で内部状態の内容を取得し、再シード処理ステップ6でこの内部状態のworking_stateを置き換えます。

予測耐性を常にサポートするように実装されている、または予測耐性を全くサポートしないように実装されているDRBGでは、このパラメータは必要ありません。ただし、予測耐性がサポートされていない場合、DRBGを利用するアプリケーションのユーザーは、そのようなDRBG実装を使用する前に、アプリケーションで予測耐性が必要かどうかを判断する必要があります。

予測耐性がサポートされていない場合、prediction_resistance_request入力パラメータと再シード処理のステップ2は省略され、再シード処理のステップ4はprediction_resistance_requestパラメータを省略するように変更されます。

予測耐性が常に実行される場合、prediction_resistance_request入力パラメータと再シード処理のステップ2は省略可能であり、再シード処理のステップ4は次のように置き換えられます。

(status, entropy_input) = Get_entropy_input (security_strength, min_length, max_length)

3) additional_input: オプションの入力。 additional_input の最大長 (max_additional_input_length) は実装依存ですが、特定の DRBG メカニズムに指定された最大値以下でなければなりません (セクション 10 を参照)。

additional_input を使用するアプリケーションによる入力がサポートされていない場合、入力パラメータと再シード処理のステップ 2 は省略され、再シード処理のステップ 5 が変更されて、パラメータリストから additional_input が削除されます。

1. entropy_input: エントロピーを含む入力ビット。この入力は、再シードされるDRBGインスタンスによって提供されてはならない。entropy_inputの最大長は実装依存であるが、選択されたDRBGメカニズムに指定された最大長以下でなければならない（セクション10を参照）。

2. DRBGがworking_stateおよび管理情報のために必要に応じて必要とする内部状態値。

再シード後の消費アプリケーションへの出力:

1. ステータス: 関数から返されるステータス。